This invention will focus on the real-time measure and use of media stream performance and capacities in a network zone. Before going into the invention's summary and disclosure, this background will address the following topics. What are real-time media streams over a network? How are media stream capabilities analyzed today? What is the Simple Network Management Protocol (SNMP)? And lastly, what are the problems with the currently available approaches?
The networking industry is rapidly converting to providing real-time media stream services, including Voice over IP (VoIP) and live video over EP. Today such services are typically packet based and create some strong demands on networks: Networks must provide low packet latencies so the information is able to arrive at the receiver's location rapidly. The incurred latency must also be stable (low jitter) so packets arrive at the receiver's location at regular intervals. Networks must also have very low packet loss so enough information is available to reconstruct the communications activity.                These VoIP telephone services are rapidly expanding worldwide and threatening traditional telephone services because they mimic ordinary telephone devices and use, but provide very affordable and reliable calling. Typical plans cost $29 a month for simple unlimited calling free throughout the United States and Canada, and exceptionally low per-minute rates to Europe and Asia. Some of the telephone sets can implemented as downloadable software to a laptop computer with a microphone and headphones, and other configurations allow ordinary telephones to be plugged in with a standard RJ-11 modular jack to a home broadband router, e.g., a Linksys Wireless-G WRT54GP2A-AT with two VoIP jacks.        Businesses are now able to set-up virtual Public Branch eXchange (PBX) networks in which some of the company's subscriber “extensions” are actually located at an employee's home and connected through a typical Linksys or Netgear broadband router. Such routers are ubiquitous in American and European homes, and a large fraction of these already support simple network protocol (SNMP) communication. Only the very inexpensive VoIP adapters do not already include SNMP.        
Global communication network operators, located at a few centralized network management centers, are relying more and more on automated network management applications to analyze, process, display and support their networks. An increasing number of network management software applications are being marketed that use open-system standardized protocols. Particular network application tool software is possible to report lists of the network appliances, by location, and can issue trouble lists and keep track of software versions and releases. SNMP applications are conventionally used to issue alarms to central management consoles when remote network appliances fail.
According to the Carnegie-Mellon Software Engineering Institute, SNMP is a network management specification developed by the Internet Engineering Task Force (IETF) in the mid 1980s to provide standard, simplified, and extensible management of LAN-based internetworking products such as bridges, routers, and wiring concentrators. An object was to reduce the complexity of network management, and to minimize the resources needed to support it. SNMP provides for centralized, robust, interoperable network management, along with the flexibility to allow for the management of vendor-specific information. SNMP as a communication specification defines how management information can be exchanged between network management applications and management agents. There are several versions of SNMP, two of the most common are SNMPv1, and SNMPv2. SNMPv1 is a simple message-based request/response application-layer protocol that uses the User Datagram Protocol (UDP) for data delivery.                SNMPv1 network management architecture includes a Network Management Station (NMS) workstation to hosts the network management application. The SNMPv1 network management application polls management agents for information and provides control information to agents.        A Management Information Base (MIB) defines the information that to be collected and controlled by the management application. Each SNMPv1 management agent provides information contained in the MIB to the management applications and can accept control information. The MIB is a database of managed objects residing on the agent. Managed objects can be monitored, modified or controlled, e.g., a threshold, network address or counter.        The management application or user can define the relationship between the SNMPv1 manager and the management agent.        The GET_NEXT_REQUEST requests the next object instance from a table or list from an agent. The GET_RESPONSE is the returned answer to get_next_request, get_request, or set_request. The GET_REQUEST asks for the value of an object instance from the agent.        The SET_REQUEST fixes the value of an object instance within an agent.        The TRAP sends trap (event) asynchronously to network management application. Agents can conditionally send a trap when a trigger has occurred, e.g., a change in state of a device, device failure or agent initialization/restart. SNMP specifies the protocol to be used between a network management application and each management agent. It allows software and managed devices from different vendors to be managed by one SNMP network management application. A “proxy function” in SNMP enables communication with non-SNMP devices to accommodate legacy equipment.        SNMP is simple to implement, and does not require large computational or memory resources from the devices that do accommodate it. SNMP network management is based on polling and asynchronous events. Each SNMP manager polls for information gathered by the agents. Each agent collects local information and stores it in the agent's own MIB. Such information is then sent later to the SNMP manager in response to the manager's polling. SNMP events (alerts) are driven by trap messages generated as a result of certain device parameters. These parameters can be either generic or vendor device specific. Enterprise-specific trap messages are vendor proprietary and generally provide more device-specific detail.        SNMPv1 has been incorporated into many products and management platforms. It has been deployed by virtually all internet working vendors. It has been widely adopted for the enterprise business organization networks. It is well-suited for managing TCP/IP networks. SNMPv1 uses the underlying User Datagram Protocol (UDP) for data delivery, which does not ensure reliability of data transfer. The loss of data may be a limitation to a network manager, depending on the criticality of the information being gathered and the frequency at which the polling is being performed.        SNMP is best suited for network monitoring and capacity planning. SNMP does not provide even the basic troubleshooting information that can be obtained from simple network troubleshooting tools. SNMP agents do not analyze information, they just collect information and provide it to the network management application.        SNMPv1 has minimal security capability. Because SNMPv1 lacks the control of unauthorized access to critical network devices and systems, it may be necessary to restrict the use of SNMP management to non-critical networks. Lack of authentication in SNMPv1 has led many vendors to not include certain commands, thus reducing extensibility and consistency across managed devices. SNMPv2 addresses these security problems but is difficult and expensive to set up and administer (e.g., each MIB must be locally set up).        Vendors often include SNMP agents with their software and public domain agents are available. Management applications are available from a variety of vendors as well as the public domain, however they can differ greatly in terms of functionality, plots and visual displays.        SNMP out-of-the-box cannot be used to track information contained in application/user level protocols (e.g., radar track message, http, mail). However these might be accomplished through the use of an extensible (customized) SNMP agent that has user defined MIB. It is important to note that a specialized or extensible network manager may be required for use with the customized agents.        There are also concerns about the use of SNMP in the real-time domain where bounded response, deadlines, and priorities are required.        SNMPv2 is intended to be able to coexist with existing SNMPv2, but in order to use SNMPv2 as the SNMP manager or to migrate from SNMPv1 to SNMPv2, all SNMPv1 compliant agents must be entirely replaced with SNMPv2 compliant agents-gateways or bilingual managers and proxy agents were not available to support the gradual migration as of early-1995. Since SNMPv1 and SNMPv2 are incompatible with each other and SNMPv2 is not stable, it is important when procuring a managed device to determine which network management protocol(s) is supported.        SNMP is conventionally used to send messages between management client nodes and agent nodes. Management information blocks (MIB's) are used for statistic counters, port status, and other information about routers and other network devices. GET and SET commands are issued from management consoles and operate on particular MIB variables for the equipment nodes. Such commands allow network management functions to be carried out between client equipment nodes and management agent nodes. The agent nodes can issue alert or TRAP messages to the management center to report special events.        SNMP is an application protocol for network management services in the internet protocol suite. SNMP has been adopted by numerous network equipment vendors as their main or secondary management interface. SNMP defines a client/server relationship, wherein the client program, a “network manager”, makes virtual connections to a server program, an “SNMP agent”, on a remote network device. The data base controlled by the SNMP agent is the SNMP management information base, and is a standard set of statistical and control values. SNMP and private MIB's allow the extension of standard values with values specific to a particular agent. Directives issued by the network manager client to an SNMP agent comprise SNMP variable identifiers, e.g., MIB object identifiers or MIB variables, and instructions to either GET the value for the identifier, or SET the identifier to a new value. Thus private MIB variables allow SNMP agents to be customized for specific devices, e.g., network bridges, gateways, and routers. The definitions of MIB variables being supported by particular agents are located in descriptor files, typically written in abstract syntax notation (ASN.1) format. The definitions are available to network management client programs.        SNMP is a standard TCP/IP protocol providing for network management. SNMP is used by network administrators to monitor and map network availability, performance, and error rates. SNMP network devices use a Management Information Base (MIB) distributed data store. SNMP compliant devices include a MIB that describes the device attributes. Some attributes are fixed or “hard coded” in the MIB, and others are dynamic values calculated by agent software running on the device. Tivoli, HP OpenView, and other enterprise network management software use SNMP commands to read and write data in each device MIB. The so-called “Get” command retrieves data, and the “Set” command initiate some action on the device. For example, a “system reboot” command is implemented by defining a particular MIB attribute and issuing an SNMP Set from the manager software to write a “reboot” value into that attribute. SNMP was developed in the 1980's. The original version, SNMPv1, was too simple and only worked with TCP/IP networks. The improved specification, SNMPv2, was developed in 1992. SNMP suffers from various flaws of its own, so many networks remained on the SNMPv1 standard while others adopted SNMPv2. More recently, SNMPv3 specification was completed in an attempt to address the problems with SNMPv1 and SNMPv2 and allow administrators to move to one common SNMP standard.        
Returning to the discussion of media streams, industry has created a number of codecs to deal with the problems created by latency, jitter, and packet loss. Each of these codecs have benefits and drawbacks depending on how they are implemented, and what sort of network qualities affect them.
To make sure that networks are reliable enough to provide for a real-time service, the industry has created a number of tests that combine a codec, latency, jitter, and packet loss reading to create a single score to determine the success of communications on that link with the codec. Mean Opinion Score (MOS) is one currently accepted method of creating a single measurement for a link. This score can be calculated via software by following the ITU-T G.107 E-model. This is a set of calculations performed with codec, latency, jitter, and packet loss.                To make networks reliable enough for real-time service, the networking industry has created test suites that combine codec, latency, jitter, and packet loss readings into a single score to describe the communications quality on links. The mean opinion score (MOS) is a popular method of quality rating a link. The MOS can be calculated with software written to the ITU-T G.107 E-model. Such software inputs codec, latency, jitter, and packet loss into its calculations. In Internet voice communications, the MOS provides a numerical measure of the quality of human speech at the destination end of the circuit. The scheme uses subjective tests, opinionated scores, that are mathematically averaged to obtain a system performance quantitative indicator.        Compressor/decompressor (codec) systems and digital signal processing (DSP) are used in voice communications to conserve bandwidth, but at the cost of voice fidelity. The best codec's provide the most bandwidth conservation while producing the least degradation of the signal. Bandwidth can be measured using laboratory instruments, but voice quality is subjective. To determine MOS, a number of listeners rate the quality of test sentences read aloud over the communications circuit by male and female speakers. A listener gives each sentence a rating of (1) bad; (2) poor; (3) fair; (4) good; (5) excellent. The MOS is the arithmetic mean of all the individual scores, and ranges 1-5, worst to best.        
Currently, there are a number of companies providing hardware and software based solutions that require setting up network agents around the network, and they will test latency, jitter and packet loss between these agents to provide a measurement. They then calculate a MOS score against a number of codecs to help determine which codec will provide the best results on your network. If there is a high latency, or high jitter, or high packet loss, this type of test will not help in determining the actual source or cause of the problem.
There are also solutions like SmokePing that will measure latency, jitter, and packet loss from one system to any other system that will respond to an Internet Command Message Protocol (ICMP) echo request. This type of solution has the obvious benefit of not requiring agents to be installed on the network. The drawback of this type of solution is that it will do nothing to help determine the actual source or cause of the high latency, jitter, or packet loss. This type of solution is also limited in the fact that it can only make measurements to or from the monitoring station. Measurements from one end point to a different end point is not possible.
Both of these types of solutions send empty packets on the network to test the conditions of the network. These “test packets” tend to be small, but can add to network overhead on bandwidth constrained links.
What is needed is a solution that will monitor latency, jitter, and packet loss for each individual link on the network, and then determine all of the possible combinations of links to determine a quality score for all possible service paths. This type of system would then be able to identify the one or more specific links in a service path that caused packet loss to be high. The network devices attached to the link(s) could then be queried for statistics to help determine the actual source of the quality problem.
For a moment, consider the requirements and background of VoIP calls. VoIP calls are made asynchronously to the network monitoring intervals. Thus, calls are made at any time, and may last for any duration.                Many VoIP phones (both soft phones and hardware phones) will provide basic statistics at the end of the call as to what the average latency, average packet loss, and average jitter was seen during the entire call. The phones don't collect additional statistics due to memory or CPU limitations on the phone.        If a user has a VoIP call that lasts 30 minutes, and the call quality (by the user's perception) is good for 29 minutes and 30 seconds, and 30 seconds of the call end up being very poor quality, then the user's perception of the call would indicate that the call was “very bad” or “unacceptable”, when the statistics over that period would show that the call quality should have been fine.        This is a result of the fact that averaging these statistics does not provide for sufficient reporting to be able to determine if a call was good or bad according to user perception.        
What is also needed is a mechanism for collecting useful statistics of a call's worst interval of performance that can be time synchronized to a network monitoring system to determine why the call had poor performance.
To summarize: today network analysis is done in a static fashion, often using pings, providing non real-time estimates based upon unreal data. These estimates may include packet loss, latency, and the variance in latency, which will be referred to as jitter herein. All of this is good, but inadequate. Actual networks are real-time creatures, responding specifically to the real-time requests and device capacities, which change and fluctuate in real-time, often dramatically affecting the performance and reliability of the delivery of media stream events, such as VoIP, web casts, video conferences, and live video over IP.
What is needed are solutions that will monitor latency, jitter, and packet loss for each individual link on the network, and then determine all of the possible combinations of links to determine a quality score for all possible service paths. This type of system would then be able to identify the one or more specific links in a service path that caused packet loss to be high. The network devices attached to the link(s) could then be queried for statistics to help determine the actual source of the quality problem.
What is also needed is a mechanism for collecting useful statistics of a call's worst interval of performance that can be time synchronized to a network monitoring system to determine why the call had poor performance.